The present invention is directed toward asset monitoring and, more particularly, toward a system and method for monitoring field devices connected to a fieldbus.
In the past, industrial processes were generally controlled by central control systems connected to field devices, such as control valves, transmitters, etc. through 4-20 mA analog networks. In recent years, there has been a movement to replace 4-20 mA analog networks with digital networks. A typical digital network (often generically referred to as a “fieldbus”) is a bi-directional, serial communications network to which “smart” field devices are connected. The field devices are “smart” in the sense that they have low-cost microprocessors for executing simple functions, such as diagnostic, control, and maintenance functions, as well as for providing bi-directional communication capabilities.
In an effort to promote the interoperability of smart field devices and controllers from different manufacturers, several fieldbus standards have been established. One of the most important of these standards is the standard established by the Fieldbus Foundation of Austin, Tex. This standard is known as the FOUNDATION fieldbus (FF) system. The FF system has three functional components, namely a physical layer, a user layer and a communication stack. These three components are derived from the Open Systems Interconnect (OSI) model.
The physical layer may be an H1 application and/or an HSE (High Speed Ethernet) application. The H1 application requires a single unshielded, twisted wire pair to provide both communication and power in an intrinsically safe manner to a field device. The H1 application has a relatively slow data rate of 31.25 kilobits/second. In contrast, the HSE application has a data rate of 100 megabits/second. It should be noted that the H1 application was developed to minimize constraints on cabling systems so as to permit many existing 4-20 mA twisted wire pairs to be used for fieldbus signals.
The user layer in the FF system is a function block application. An FF function block is a software module designed to perform a specific set of operations on or more inputs to generate one or more outputs. Function blocks reside in the various devices of a fieldbus network to implement a control strategy. A function block is evaluated, or executed, on a periodic basis under control of the device in which it resides. Communication among function blocks takes place through linkages that are established by a configuration procedure, before startup or during operation.
The communication stack recognizes several different classes of field devices including: link master, basic, linking device and gateway. A link master controls all communication in a fieldbus network. The link master contains a function called a link active scheduler (LAS) and is typically a host device located in a central control room. A basic device is capable of all basic communication required of a field device and interacts with the host device in a client/server manner, wherein the host device is the client and the basic device is the server. A linking device is used to connect an H1 segment to an HSE segment. Typically, a linking device connects several H1 segments to an HSE segment. The primary function of a linking device is to insert or remove an FF message into or from Ethernet message and to provide a routing function among the various segments and devices. A gateway device is used to connect an FF system to some other, non-FF system, such as a Modbus system.
The communication stack provides for three types of communication between field devices: publisher/subscriber, report distribution and client/server.
In publisher/subscriber communication, process data for real time control is transmitted on a precisely periodic time schedule (i.e., is cyclic data) to provide satisfactory dynamic control of plant processes. Such process data is buffered, i.e., current process data is transmitted and older process data is overwritten. In publisher/subscriber communication, process data is broadcast on a fieldbus network from a single source to any device needing the process, i.e., is “one-to-many”.
Report distribution communication is used for alert data, which may be an alarm or an event. Unlike process data, alert data is queued, i.e., the alert data is not overwritten and is communicated at the earliest opportunity after the occurrence of the underlying event, rather than on a scheduled basis. Thus, alert data is non-cyclic data. The appropriate recipient of alert data must confirm receipt by sending a return confirmation. Otherwise, the original transmission of the alert data will be periodically re-transmitted. Report distribution communication is initiated by a sender and is “one-to-many”, similar to publisher/subscriber communication.
For purposes of monitoring equipment assets, alarms and events can be categorized in two groups: (1.) alarms and events for plant operation, e.g. an alarm is activated when a process value meets or exceeds a preset limit; and (2) alarms and events reporting equipment status, e.g. “maintain equipment soon”.
Client/server communication is similar to report distribution communication, except the communication is between two specific devices, i.e., is “one-to-one” communication. Client server communication is used for operator access data (such as set point and tuning changes) and diagnostic data.
With regard to diagnostics, an asset monitoring software program (or simply “asset monitor”) in a central control system may periodically request (poll) diagnostic data from devices in the fieldbus network. The diagnostic data is pooled from the devices and periodically sent to the asset monitoring software program. This polling of diagnostic data, however, creates a substantial load on the slow H1 link of the fieldbus network. In order to reduce the network traffic on the H1 link, the asset monitor could only subscribe to alarms and events (alerts) reporting equipment status, thereby eliminating the need to continuously poll the devices for diagnostic data. The downside to this approach, however, is that there is not enough information in the alerts to assess the health of the devices. Furthermore once such a maintenance alert has been activated, no new maintenance alert will be produced until the previous maintenance alert is deactivated (returns to normal).
Based on the foregoing, there is a need for an improved system and method for providing diagnostic information from FF devices to an asset monitor. The present invention is directed to such a system and method.